home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1089 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.2 KB
  1. Subject: Gem List
  2. Subject:  Getting right mouse button clicks
  3. Subject:  Hot Tracking, and other digestion
  4. Subject:  Re: Gem List
  5. Date: Wed, 27 Jul 94 20:59 EST
  6. From: "Daniel J. Hollis" <0006795560@mcimail.com>
  7. To: ems <gem-list@world.std.com>
  8. Subject: Gem List
  9. Message-Id: <75940728015957/0006795560PK1EM@mcimail.com>
  10. Precedence: bulk
  11.  
  12. Subject:  Getting right mouse button clicks
  13.  
  14. David:
  15. ------ 
  16. > What I need is Right mouse button clicks AND double-left-click information. 
  17. > Possible?
  18.  
  19. To get right mouse button clicks, simply use vq_mouse and get the correct
  20. information from VDI, or use event_dclick for the double click information.
  21.  
  22. > For the moment I'm using the mouse event grabbing technique, simply turning 
  23. > it on when I'm in the section of window which needs RMB detection and off 
  24. > otherwise.
  25.  
  26. This works, but you have to enable BOTH button DOWN flags, and you need to
  27. set the number of clicks to 1.  However, you could use 2, but this is
  28. not recommended, as AES will be forced to wait for two mouse clicks, and will
  29. not stop at one.
  30.  
  31. -- Ken Hollis (Bitgate Software)
  32. -----
  33. Subject:  Hot Tracking, and other digestion
  34.  
  35. Warwick:
  36. --------
  37. > This opens up a large relm of possibilities if this can become a common
  38. > feature of GEM applications:
  39.  
  40. You've mentioned some interesting ideas, almost all of which I agree on.
  41. Although, I have a question about this:
  42.  
  43. >    1. Point-to-type
  44.  
  45. I hope not...  What happens if the mouse is bumped on accident when the
  46. user is typing?  This can be extremely frustrating, especially for those of
  47. us who are fortunate enough to have a STacy or those of us with more than
  48. one cat.  :-)
  49.  
  50. >    3. Pointer-form change
  51.  
  52. Good idea.
  53.  
  54. >    4. Balloon help (ala Mac)
  55.  
  56. *EXCELLENT* idea.  But, this could even be added to a "status" bar inside
  57. a window.  I think you could put a form in the window at the very bottom,
  58. and have something like ChangeStatusText(window, "text") on a dialog button
  59. activation, or when the mouse pointer is over an object.  This would make
  60. things very nice, and easy to work with.  Of course, it's your choice,
  61. but it's a good idea, any how.
  62.  
  63. > Yet, it *is* GEM. 
  64.  
  65. Anything dealing with AES is considered GEM. :-P
  66.  
  67. > So the question is, should or should not newer applications exploit more
  68. > and more of GEM's features, such as rectangle lists?
  69.  
  70. Good question.  I for one support the idea of rectangle lists, and am about
  71. to add them in my program, particularly for scrollable dialog boxes (for
  72. those of us who are unfortunate to have a small viewing screen...)
  73.  
  74. > Should they Iconize windows?
  75. > Should they use dialogs-in-windows?
  76. > Should they use the extended (titled) file selector call?
  77.  
  78. These should all be standards, IMHO.
  79.  
  80. (See, we CAN agree on some things!  :)
  81.  
  82. -- Ken Hollis (Bitgate Software)
  83. -----
  84. Subject:  Re: Gem List
  85.  
  86. Kevin:
  87. ------ 
  88. > Surely its as simple as not checking for WM_TOPPED messages for it in
  89. > your event loop. If you're doing it as part of a library then simply attach
  90. > a flag to your window structure to indicate this and check against it in
  91. > the event loop.
  92.  
  93. No.  It IS that easy.  Simply trap the WM_TOPPED message.  All you have to
  94. do when you receive it is to:
  95.  
  96. If the button is no longer pressed when you process the message, top the
  97. window.  This means that the button was tapped on the window with the intent
  98. to bring it to the front.
  99.  
  100. If the button is pressed when you process the message, then do the following:
  101.  
  102.     - Find the dialog under the window that was "topped" and process
  103.       the dialogs in the background as you would normally.
  104.     - Do an object select/deselect for that window
  105.     - Process the object like it is topped
  106.  
  107. Simple.  :-)  This is how XAES handles it, and it works fine.
  108.  
  109. > Or any other non-standard extensions that come to mind, like cut and paste
  110. > from text fields, improved character entry verification, multi-line text
  111. > fields, etc. 
  112.  
  113. And, speaking of cut-and-paste, you can get a demonstration that shows off
  114. something like this on ftp.sys.uea.ac.uk, under pub/sowerby.  Get the file
  115. "fluid.zoo" and check it out.  It's very good, and it shows the idea of
  116. cut-and-paste for editing objects.  As for improved character entry
  117. verification, that can be done without an objc_edit routine.  Multi-line
  118. text fields cannot be done w/o a custom routine, but it's not hard to do.
  119.  
  120. -- Ken Hollis (Bitgate Software)
  121.